---
title: Rootless mode & OpenShift
sidebar_label: Rootless mode & OpenShift
---

import NonRootSegment from '../fragments/non-root-vcluster.mdx'
import OpenshiftSegment from '../fragments/deploy-to-openshift.mdx'

Many Kubernetes cluster operators employ policies to restrict the usage of certain features, for example running pods with the root user.
On this page you will see which options allow you to adjust vcluster configuration to successfully deploy it in such restricted host clusters.

## Running as non-root user
If your host cluster policies disallow running containers with root user, or you simply preffer to run them this way, it is possible to configure it for vcluster components. Steps below show how to set the desired UID for syncer and control plane. The syncer also passes this UID down to the vcluster DNS deployment.

<NonRootSegment/>

:::info Values of the securityContext fields
You can substitute the runAsUser value as needed, e.g. if the host cluster limits the allowable UID ranges.  
And you are free to set other [securityContext fields](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podsecuritycontext-v1-core) as necessary to fulfill your host cluster policies.
:::

:::caution
Running as non-root is currently supported only for the k3s distribution. While [other distributions provided by vcluster](./other-distributions) may make use of the `securityContext` field from the `values.yaml` file, we do not guarantee that they will work as expected.
:::

:::caution
vcluster doesn't currently provide a migration path from an instance that was running as root to running with a non-root user.
:::

## Running on OpenShift
By default, OpenShift doesn't allow running containers with the root user, but it assings a random UID from the allowed range automatically, which means that you can skip the steps described in the [Running as non-root user](#running-as-non-root-user) section of this document and your vcluster should run as non-root user by default.

OpenShift also imposes some restrictions that are not common to other Kubernetes distributions.  
When deploying vcluster to OpenShift you will need to follow these additional steps:

<OpenshiftSegment/>

:::info Additional permission when running on OpenShift
vcluster requires `create` permission for the `endpoints/restricted` resource in the default group when running on OpenShift.  
This permission is required because OpenShift has additional built-in admission controller for the Endpoint resources, which denies creation of the endpoints pointing into the cluster network or service network CIDR ranges, unless this additional permission is given.
Following the steps outline above ensures that the vcluster Role includes this permission, as it is necessary for certain networking features. 
:::